Pracuję z Power Automate Desktop od ponad roku. W tym czasie spotkałem się z wieloma dziwnymi błędami, które pojawiały się gdzieś pomiędzy cloud flows, których używałem do wyzwalania RPA, a samymi botami. W tym poście spróbuję pomóc Ci zrozumieć, skąd pochodzą i jak je rozwiązać (lub obejść).

W tym poście skupiam się na błędach, które mogą wystąpić w nadzorowanym (attended) lub nienadzorowanym (unattended) przepływie Power Automate Desktop pojawiających się zasadniczo w warstwie sieciowej w sytuacjach, gdy instancje RPA są wyzwalane przez cloud flows. Błędy mogą wystąpić z obu stron, gdy cloud flow wyzwala desktop flow, a później, gdy desktop flow próbuje wysłać dane z powrotem do cloud flow, który go wyzwolił.

Błędy w Power Automate Desktop

Za każdym razem, gdy w przepływie desktop flow wystąpi błąd, zostanie on zwrócony jako poniższy obiekt JSON:

{
    "error": {
        "code": "[INTERNAL CODE]",
        "message": "[HUMAN READABLE ERROR DESCRIPTION]"
    }
}

Kody są oczywiście unikalne i są najważniejszymi informacjami, które pomagają nam debugować i rozwiązywać problemy. Skoncentruję się teraz na tych, z którymi miałem do czynienia najczęściej.

Rozwiązywanie problemów z Power Automate Desktop

Error code: NoCandidateMachine

Status code: 400

Kiedy? Ten błąd występuje, gdy przepływ cloud flow nie może połączyć się z żadną zapisaną maszyną przez czas dłuższy niż trzy godziny. Błąd może wystąpić, nawet jeśli maszyna jest dostępna, ale z powodu problemów z siecią (lub prawdopodobnie błędów w konfiguracji lokalnej zapory sieciowej na komputerze) przepływ cloud nie może się do niego dostać przy użyciu zapisanych informacji o rejestracji maszyny (machine registration). Występuje zawsze przed faktycznym wykonaniem przepływu pulpitu.

Jak to rozwiązać? Możesz oczywiście skontaktować się z pomocą techniczną firmy Microsoft, aby uzyskać pomoc w rozwiązaniu problemów z komunikacją sieciową w takim przypadku. To, co ja robię, to dwie rzeczy: zmiana konfiguracji ponawiania w ustawieniach akcji i ponowne uruchomienie przepływu pulpitu, o ile taki błąd nie zostanie zwrócony:

Przy takim ustawieniu zasad ponawiania w przypadku wystąpienia jakiegokolwiek problemu z grupy 5xx, flow spróbuje samodzielnie ponowić próbę. I druga sztuczka:

Ma na celu sprawdzenie, czy treść odpowiedzi z akcji PAD zawiera określony schemat błędu. Jeśli tak, czy „code” jest równy „NoCandidateMachine”. W takim przypadku wstrzymuję przepływ na 5 minut, a następnie próbuje ponownie uruchomić PAD. Pętla kończy się, gdy PAD zakończy się bez błędu lub zostanie zwrócony inny rodzaj kodu błędu.

Error code: NoListenerConnected

Status code: 400

Kiedy? Ten błąd pojawia się ponownie w sytuacji, gdy przepływ cloud próbuje wyzwolić przepływ desktop, ale z powodu problemów z siecią nie może „skonktaktować” się z komputerem. Nie wiem dokładnie na czym polega różnica między tymi błędami, ale do tej pory odkryłem, że ten błąd występuje tylko w fazie inicjacji, a więc nie podczas wykonywania przepływu desktop.

Jak to rozwiązać? Postanowiłem zaimplementować podobne obejście dla tego scenariusza, jak opisałem powyżej. Ale – rozszerzyłem mechanizm opisany dla błędu NoCandidateMachine o obsługę innych scenariuszy:

Jak widać, tutaj zmienna, która służy do weryfikacji, czy pętla powinna zostać zakończona, jest po prostu tekstem zawierającym wartość ERROR lub nie. Tak więc w przypadku wystąpienia któregokolwiek z wymienionych błędów, przepływ w chmurze jest ponownie wstrzymywany, a następnie wykonywana jest próba ponownego uruchomienia przepływ desktop.

Error code: ConnectionNotEstablished

Status code: 400

Kiedy? Błąd najprawdopodobniej występuje z powodu problemów z siecią/połączeniem między chmurą a maszyną, na której bot powinien zostać uruchomiony. Nie odkryłem jeszcze samego źródła tego zachowania. Pozytywną informacją jest to, że błąd występuje podczas inicjalizacji bota, więc żadne akcje nie są jeszcze wykonane.

Jak to rozwiązać? Polecam skorzystać z tego samego rozwiązania, co powyżej – tak aby wyzwalać akcję PAD, dokąd nie zwraca błędu.

Error message: Desktop flow execution failed. CorrelationId: '00000000-0000-0000-0000-000000000000′

Kiedy? Błąd pojawia się niestety w trakcie wykonywania przepływu desktop. I (w moim przypadku) tylko na końcu instancji PADa, a więc gdy bot próbuje zapisać swój log z powrotem do chmury i zwrócić dane zmiennych wyjściowych lub informacje o błędach. Ten problem jest bardzo kłopotliwy, ponieważ w rzeczywistości powoduje zakończenie przepływu cloud z błędem, mimo że przepływ desktop mógł zostać pomyślnie zakończony. Co więcej, po przejściu do „Monitora przepływów pulpitu” nie będzie dostępna żadna historia dla tej instancji 🙁

Ważne! Zanim powiem Ci, jak to rozwiązać, zawsze możesz znaleźć log instancji, gdy zalogujesz się do komputera, na którym bot został uruchomiony (najlepiej na to samo konto, które zostało użyte do połączenia), a następnie przejdziesz do: %LOCALAPPDATA%\Microsoft\Power Automate Desktop\Scripts. Znajdziesz tam folder z guid równym guid definicji przepływu desktop. Wewnątrz folderu przejdź do \Runs\ i poszukaj folderu z identyfikatorem guid równym identyfikatorowi określonej instancji tego przepływu desktop. Wewnątrz tego folderu znajdziesz plik „Actions.log”, który zawiera JSON z pełny logiem.

Jak to rozwiązać? Niestety nie ma łatwego sposobu na rozwiązanie tego problemu. Musisz znaleźć sposób na sprawdzenie, w ramach przepływu cloud, czy ten konkretny przepływ desktop rzeczywiście zakończył się pomyślnie, czy z błędem. To, co ja robię, to dodatkowe logowanie i rozszerzona obsługa błędów w przepływach desktop. Każda instancja tworzy osobny plik Excel, który jest używany przez przepływ desktop do zapisywania informacji z jego działania. Ostatni wiersz to zawsze albo informacja, że bot zakończył pomyślnie, albo informacja o przechwyconym wyjątku. Następnie w procesie przepływu cloud sprawdzam ostatni wiersz tego pliku Excel, aby określić, czy wystąpił błąd, czy nie:

W przypadku, gdy wartość w ostatnim wierszu jest inna niż „RPA completed”, przepływ cloud uznaje tę instancję przepływu desktop za nieudaną i działa odpowiednio. We wszystkich innych scenariuszach kończy się scenariuszem poprawnego uruchomienia.

Error code: ActionRuntimeError

Status code: 400

Kiedy? Błąd często jest uzupełniony np. komunikatem: "Runtime Error: Exception of type 'System.OutOfMemoryException' was thrown. - issue related to machine". I jak powyżej, ten problem może wystąpić w dowolnym momencie podczas wykonywania przepływu desktop. Jest jednak o wiele bardziej problematyczny niż wspomniany powyżej. Kiedy nastąpi, po prostu kończy instancję przepływu desktop, mimo tego, że może znajdować się nawet w środku jakiejś transakcji. Dzieje się tak z powodu problemów na maszynie, na której wykonywany jest bot. Na przykład z powodu niewystarczających zasobów: RAM, HDD itp. Może się zdarzyć, że bot zbiera dużo danych podczas działania (np. tworzy dużą zmienną tekstową przez doklejanie nowego tekstu przez cały czas działania) i wyczerpuje zasoby.

Jak to rozwiązać? Oczywiście sprawdź, jaki był powód błędu. Ewentualnie możesz to naprawić, dodając więcej zasobów do maszyny. Niestety nie mam łatwego do wdrożenia rozwiązania. W rzeczywistości musisz sprawdzić, na której akcji bot zwrócił wyjątek i na tej podstawie wybrać najlepsze podejście do ponownego uruchomienia go. Na przykład, jeśli przetwarzał listę rekordów, lepiej byłoby wyzwolić go tylko dla nieprzetworzonych rekordów. Oczywiście w tym przypadku przydatne może być również niestandardowe logowanie, na przykład jeśli bot aktualizuje listę przetworzonych rekordów, może później przekazać ją do przepływu w chmurze, który może następnie ponownie uruchomić bota dla pozostałych rekordów.

Error code: SessionNotFound

Status code: 400

Kiedy? W moim przypadku ten błąd występował tylko wtedy, gdy przepływ cloud próbował wyzwolić przepływ desktop. Został on uzupełniony komunikatem: "Can't find target session". Doradzono mi, aby sprawdzić, czy maszyna, na której miał być uruchomiony przepływ pulpitu, nie została utworzona przez procedurę „klonowania” na platformie Azure. W moim przypadku tak właśnie było. Powodem wystąpienia tego błędu było to, że wiele komputerów zostało faktycznie zarejestrowanych pod tym samym identyfikatorem, więc chmura nie była w stanie znaleźć tego konkretnego.

jak to rozwiązać? Po prostu ponownie zarejestruj urządzenie, które powoduje błąd. Aby to zrobić, przejdź do tego komputera, w ustawieniach „Machine registration” połącz go z innym środowiskiem, a następnie z powrotem z tym, w którym ma być dostępny. Na koniec odśwież zdefiniowane połączenia w powiązanym środowisku Power Platform.

Error code: RunFlowFailedError

Status code: 400

Kiedy? Błąd jest uzupełniony komunikatem: „Failed to run flow \r\n Timeout has expired.„. Błąd może wystąpić, gdy używasz akcji „Uruchom przepływ pulpitu” w przepływie desktop (który wyzwala inny przepływ desktop) i ów inny przepływ desktop działa zbyt długo (i przekrocza timeout). Ponownie – jest to kłopotliwy błąd, ponieważ zdarza się podczas wykonywania przepływu desktop.

Jak to rozwiązać? Podobnie jak w przypadku "ActionRuntimeError" musisz najpierw sprawdzić, co było przyczyną błędu, a następnie odpowiednio zareagować. Przejdź do monitora „przepływów pulpitu” i sprawdź nieudaną instancję przepływu, aby dowiedzieć się, która akcja się nie powiodła i być może dlaczego – miejmy nadzieję, że zrzut ekranu może Ci pomóc.

Error code: RunFlowFailedError – An error occurred while executing flow Stack empty.

Status code: 400

When? Błąd jest uzupełniony komunikatem: „Failed to run flow \r\n An error occurred while executing flow Stack empty.„. Błąd może wystąpić, gdy używasz akcji „Uruchom przepływ pulpitu” w przepływie desktop (który wyzwala inny przepływ desktop) i ów inny przepływ desktop został zmodyfikowany i zapisany przy użyciu nowszej wersji PAD Designer niż używana na maszynie, na której jest uruchamiany.

Jak to rozwiązać? W moim przypadku, wystarczającym zabiegiem była aktualizacjia PAD na maszynie, gdzie przepływ był uruchamiany, do najnowszej wersji.

Inne błędy

Jeśli napotkałeś inny typ błędu, daj mi znać w komentarzach, z przyjemnością zaktualizuję post i dołączę podjęte przez Ciebie kroki.

Ponadto w Microsoft Docs znajduje się lista znanych błędów, więc jeśli nie możesz znaleźć rozwiązania w tym poście, być może będziesz miał więcej szczęścia tam. Po prostu przejdź do: Windows sessions and UI flows and attended/unattended behavior – Power Automate | Microsoft Docs.